1. Technical Field
This invention relates in general to data communications and, more particularly, to performance monitoring of frame transmission in a data network.
2. Description of the Related Art
There is a growing demand for network performance monitoring in data network. Until recently, this network performance monitoring was used mostly for network troubleshooting (network management, status and alarms) in addition to usual methods of connectivity tests. Now, it is also needed for SLA (Service Level Agreement) checking, billing, and network security (flood attack detection, etc.). Accordingly, the status of performance monitoring is changing from an interesting endeavor to one that is necessary and required.
While network performance measuring at layers 3 and above, with limited accuracy, was previously sufficient, more accuracy is currently needed. Next generation networks require higher accuracy and more integration in the network management and the protocols. Delay, delay variation (“jitter”), and loss are three critical metrics to estimate the quality of essential services like voice and video streaming for instance. Operators and providers must be able to measure these metrics, so as to verify that they actually provide the agreed SLA to their customers, and to detect and react quickly should the metrics fall under the agreed levels.
In general, performance monitoring can be achieved either passively (i.e. by observing actual user traffic and possibly adding some specific marking information) or actively (i.e. by injecting extra control traffic for the purpose of performance measurement). Active solutions are usually preferred, since they are much easier to deploy, although they are inherently less accurate because they inject extra traffic into the same network that they are measuring. Passive solutions are more accurate, but require more complex architectures, essentially to correlate the observed packets at ingress and egress.
One form of a passive performance monitoring solution consists of maintaining local counters in nodes (information traps). RMON (Remote Monitoring) is an example of counter-based solution (IETF RFC2819 for RMON-1, RFC 2021 for RMON-2). The data is stored in MIBs (Management Information Bases) and exchanged usually via SNMP (Simple Network Management Protocol). Counters keep track of data such as number of octets, frames, errors, collisions, type (broadcast, multicast), size buckets (frames between 64 and 127 octets, etc.), or more specific information such as a count of octets between pairs of endnodes, identified, for instance, by their MAC (Media Access Control) addresses (“matrix”-type counters). Alarms can be raised by an RMON probe, based on user-defined thresholds or filters: for instance, if a counter exceeds a certain threshold, the probe will raise an alarm. Filters allow to capture the frames that match a certain filter (for post-replay for example, or just event logging).
A problem with using counters is that local counters do not provide the basis for a measurement of Delays or Delay Variations. In the measurement of Losses, there needs to be an exchange of counter information between a sending node and a receiving node in order to correlate between the observed frames, which adds a layer of complexity to the measurement.
Most of today's performance monitoring systems are implemented at layer-3 (IP level). IPPM (IP Performance Metrics) is an IETF work group responsible for defining the metrics and providing guidance for implementation. In particular, the theoretical foundation for statistical significance of measurement is provided. IPPM has issued a number of RFCs: 2330, 2678, 2679, 2680, 2681, 3148, 3357, 3393, 3442, and is working on drafts for a signalling protocol (OWAMP: One-Way Active Measurement Protocol) and new metrics (multiparty and reordering). ITU has released ITU-T documents Y.1540 and Y.1541. Software tools for IP-level performance measurement abound (wvww.caida.org., www.ripe.net/test-traffic/) and several vendors provide some form of software or hardware for IP-level performance monitoring, in addition to the usual user traffic counters used for measuring error rates, bandwidth usage, etc. U.S. Pat. Nos. 6,868,094 and 6,868,068 describe IP level measurement systems.
The methodological approach from IETF's IPPM (randomization, measurement error analysis with calibration) provides good statistical significance, but the layer at which it is applied unfortunately reduces the quality of the measurement. At the IP level, a stream of packets from a source to a destination may use different paths, so the obtained measurements can be different even if everything else is the same otherwise. Moreover, a general implementation rule is that the farther the measurement module is from the line interface, the less accurate the timestamping will be. Additionally, the measurement packet approach has to be deployed separately, since it is not part of a standardized OAM infrastructure for IP: this is a problem for operators, who prefer simplicity and automation (integration of the performance monitoring directly in the OAM framework). Further, IPPM requires the creation of a session for measuring performance.
Another array of solutions consists in adding overlay measurement equipment (using a separate box with several modules, or compatible third party board/module using a slot in a vendor node, or even mobile handheld device) to an existing network. This additional equipment may include other functions, typically protocol conformance testing, physical signal quality verification (electrical or optical), etc. Performance monitoring using overlay equipment can be performed at any layer, including the application layer (for instance, fake phone calls are generated to monitor VoIP performance).
Performance measurement using overlay equipment, however, can greatly increase the cost of monitoring a network.
Therefore, a need has arisen for a accurate, cost effective method and apparatus for performance monitoring in a data network.